(Thanks to the poor formatting options for forum comments, I'll need to respond to this this in a top-level answer, below.)

You are welcome! Glad to help. So it sounds like you found that answer... "acceptable"? 😉

One wrinkle to be aware of: if the user deliberately kills your app in the background, maybe because they read on social media that killing all your background apps will make your device work better, then it kills your pending background upload (along with other features like background fetch). You'll get an appropriate delegate call for the failed upload on next launch, which you'll need to handle to retry the upload if needed. Unfortunately I've found that telling your frantically app-killing friends "that doesn't do what you think it does" rarely helps.

That revised next() function does generate a sequence of values spaced uniformly across the range of possible Int64 values, and this happens to make the current version of randomElement() behave as desired in this case, but it’s still not future-proof.

I'm thinking it should be sufficient to just create a new user account, install the recovered data there, and then delete the old damaged account. This assumes the command was run in their home directory, which should be the default when launching Terminal.

Just curious, what's the issue forcing you to stay on Xcode 12.2? If you're stuck on macOS 10.15 Catalina, then (according to the release notes) you should at least be able to use Xcode 12.4. Not a huge difference of course, but I'm sure you know that the farther you fall behind, the worse life gets. ;-)

As a slightly different approach, consider if calculateETA() will work for you. It’s documented as being more lightweight than calculate(). And since an ETA is literally only an estimate, throttle your call rate way down, maybe only once per minute. (Way different than trying to "evade" the throttling I mentioned above; by that I meant trying to figure out exactly how fast you could get away with it.) Updating the UI any faster than that wouldn't necessarily have been any more useful.

Unfortunately you're not really missing anything. You can't access the filesystem outside your sandbox, so checking for other apps that way won't work. But hopefully it’s not so bad to publish a new app update whenever needed. You could just use the vague "Bug fixes and performance improvements" line, and users will think you're really putting a lot of work into it. 😉

But note this 50 item limit is deliberate new behavior (see the updated documentation linked in that other thread) so it’s probably better to frame your feedback as a request for refinement rather than a bug. As mentioned in the other thread, maybe well behaved apps could be accommodated by a new entitlement or by special attention during review.

(Duplicate comment removed due to forum problem. I commented, then the comment disappeared, so I added the comment again, and then the original comment reappeared. Ugh.)

It crashes for me using either SwiftUI or Storyboard style project. The key is to create the project new in Xcode 13, which turns on the Generate Info.plist File build setting. Projects created in Xcode 12 or earlier don't have that setting so everything works as before. Or you could enable that setting in an existing project (which is what I was originally trying to do) but then things get messy fast. That's an advanced move. ;-)

Submitted FB9698458.

Submitted feedback FB9842277 suggesting a rewrite of the documentation for CFBundleVersion.

And if the original file does have invisible content, it could get lost when pasting the text into this forum, resulting in nobody else being able to reproduce the problem.

Use the “Paste and Match Style” (⌥⇧⌘V) command in the Edit menu in Safari. Don’t use the regular Paste (⌘V) command.